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USB in a NutShell 

Making sense of the USB standard 

Starting out new with USB can be quite daunting. With the USB 2.0 specification at 
650 pages one could easily be put off just by the sheer size of the standard. This is 
only the beginning of a long list of associated standards for USB. There are USB 
Class Standards such as the HID Class Specification which details the common 
operation of devices (keyboards, mice etc) falling under the HID (Human Interface 
Devices) Class - only another 97 pages. If you are designing a USB Host, then you 
have three Host Controller Interface Standards to choose from. None of these are 
detailed in the USB 2.0 Spec. 



The good news is you don't even need to bother reading the entire USB standard. 
Some chapters were churned out by marketing, others aimed at the lower link layer 
normally taken care off by your USB controller IC and a couple aimed at host and 
hub developers. Lets take a little journey through the various chapters of the USB 
2.0 specification and briefly introduce the key points. 



Chapter 
1 



Name 
Introduction 



Terms and 
Abbreviations 

Background 



Architectural 
Overview 



USB Data 
Flow Model 



Description Pages 

Includes the motivation and scope for USB. The most 2 
important piece of information in this chapter is to make 
reference to the Universal Serial Bus Device Class 
Specifications. No need reading this chapter. 

This chapter is self-explanatory and a necessary evil to 8 
any standard. 

Specifies the goals of USB which are Plug'n'Play and 4 
simplicity to the end user (not developer). Introduces 
Low, Full and High Speed ranges with a feature list 
straight from marketing. No need reading this chapter 
either. 

This is where you can start reading. This chapter 10 
provides a basic overview of a USB system including 
topology, data rates, data flow types, basic electrical 
specs etc. 

This chapter starts to talk about how data flows on a 60 
Universal Serial Bus. It introduces terms such as 
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endpoints and pipes then spends most of the chapter on 
each of the data flow types (Control, Interrupt, 
Isochronous and Bulk). While it's important to know each 
transfer type and its properties it is a little heavy on for a 
first reader. 

Mechanical This chapter details the USB's two standard connectors. 33 
The important information here is that a type A 
connector is oriented facing downstream and a type B 
connector upstream. Therefore it should be impossible 
to plug a cable into two upstream ports. All detachable 
cables must be full/high speed, while any low speed 
cable must be hardwired to the appliance. Other than a 
quick look at the connectors, you can skip this chapter 
unless you intend to manufacture USB connectors 
and/or cables. PCB designers can find standard 
footprints in this chapter. 

Electrical This chapter looks at low level electrical signalling 75 
including line impedance, rise/fall times, driver/receiver 
specifications and bit level encoding, bit stuffing etc. The 
more important parts of this chapter are the device 
speed identification by using a resistor to bias either data 
line and bus powered devices vs self powered devices. 
Unless you are designing USB transceivers at a silicon 
level you can flip through this chapter. Good USB device 
datasheets will detail what value bus termination 
resistors you will need for bus impedance matching. 

Protocol Now we start to get into the protocol layers. This chapter 45 
Layer describes the USB packets at a byte level including the 
sync, pid, address, endpoint, CRC fields. Once this has 
been grasped it moves on to the next protocol layer, 
USB packets. Most developers still don't see these lower 
protocol layers as their USB device IC's take care of this. 
However a understanding of the status reporting and 
handshaking is worthwhile. 

USB Device This is the most frequently used chapter in the entire 36 
Frame Work specification and the only one I ever bothered printing 
and binding. This details the bus enumeration and 
request codes (set address, get descriptor etc) which 
make up the most common protocol layer USB 
programmers and designers will ever see. This chapter 
is a must read in detail. 



10 USB Host This chapter covers issues relating to the host. This 23 
Hardware includes frame and microframe generation, host 

and Software controller requirements, software mechanisms and the 
universal serial bus driver model. Unless you are 
designing Hosts, you can skip this chapter. 

1 1 Hub Details the workings of USB hubs including hub 143 
Specification configuration, split transactions, standard descriptors for 

hub class etc. Unless you are designing Hubs, you can 
skip this chapter. 



So now we can begin to read the parts of the standard relevant to our needs. If you 
develop drivers (Software) for USB peripherals then you may only need to read 
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chapters, 

■ 4 - Architectural Overview 

■ 5 - USB Data Flow Model 

■ 9 - USB Device Frame Work, and 

> 10 - USB Host Hardware and Software. 

Peripheral hardware (Electronics) designers on the other hand may only need to 
read chapters, 

■ 4 - Architectural Overview 

> 5 - USB Data Flow Model 

■ 6 - Mechanical, and 
ml- Electrical. 



USB in a NutShell for Peripheral Designers 

Now lets face it, (1) most of us are here to develop USB peripherals and (2) it's 
common to read a standard and still have no idea how to implement a device. So in 
the next 7 chapters we focus on the relevant parts needed to develop a USB 
device. This allows you to grab a grasp of USB and its issues allowing you to 
further research the issues specific to your application. 

The USB 1.1 standard was complex enough before High Speed was thrown into 
USB 2.0. In order to help understand the fundamental principals behind USB, we 
omit many areas specific to High Speed devices. 

Introducing the Universal Serial Bus 

USB version 1.1 supported two speeds, a full speed mode of 12Mbits/s and a low 
speed mode of 1 .5Mbits/s. The 1 .5Mbits/s mode is slower and less susceptible to 
EMI, thus reducing the cost of ferrite beads and quality components. For example, 
crystals can be replaced by cheaper resonators. USB 2.0 which is still yet to see 
day light on mainstream desktop computers has upped the stakes to 480Mbits/s. 
The 480Mbits/s is known as High Speed mode and was a tack on to compete with 
the Firewire Serial Bus. 

USB Speeds 

o High Speed - 480Mbits/s 
o Full Speed - 12Mbits/s 
o Low Speed - 1.5Mbits/s 

The Universal Serial Bus is host controlled. There can only be one host per bus. 
The specification in itself, does not support any form of multimaster arrangement. 
However the O n -The-Go specification which is a tack on standard to USB 2.0 has 
introduced a Host Negotiation Protocol which allows two devices negotiate for the 
role of host. This is aimed at and limited to single point to point connections such as 
a mobile phone and personal organiser and not multiple hub, multiple device 
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desktop configurations. The USB host is responsible for undertaking all 
transactions and scheduling bandwidth. Data can be sent by various transaction 
methods using a token-based protocol. 

In my view the bus topology of USB is somewhat limiting. One of the original 
intentions of USB was to reduce the amount of cabling at the back of your PC. 
Apple people will say the idea came from the Apple Desktop Bus, where both the 
keyboard, mouse and some other peripherals could be connected together (daisy 
chained) using the one cable. 

However USB uses a tiered star topology, simular to that of 10BaseT Ethernet. This 
imposes the use of a hub somewhere, which adds to greater expense, more boxes 
on your desktop and more cables. However it is not as bad as it may seem. Many 
devices have USB hubs integrated into them. For example, your keyboard may 
contain a hub which is connected to your computer. Your mouse and other devices 
such as your digital camera can be plugged easily into the back of your keyboard. 
Monitors are just another peripheral on a long list which commonly have in-built 
hubs. 

This tiered star topology, rather than simply daisy chaining devices together has 
some benefits. Firstly power to each device can be monitored and even switched 
off if an overcurrent condition occurs without disrupting other USB devices. Both 
high, full and low speed devices can be supported, with the hub filtering out high 
speed and full speed transactions so lower speed devices do not receive them. 

Up to 127 devices can be connected to any one USB bus at any one given time. 
Need more devices? - simply add another port/host. While most earlier USB hosts 
had two ports, most manufacturers have seen this as limiting and are starting to 
introduce 4 and 5 port host cards with an internal port for hard disks etc. The early 
hosts had one USB controller and thus both ports shared the same available USB 
bandwidth. As bandwidth requirements grew, we are starting to see multi-port cards 
with two or more controllers allowing individual channels. 

The USB host controllers have their own specifications. With USB 1.1, there were 
two Host Controller Interface Specifications, UHCI (Universal Host Controller 
Interface) developed by Intel which puts more of the burden on software (Microsoft) 
and allowing for cheaper hardware and the Q HCI (Open Host Contro lle r Interface) 
developed by Compaq, Microsoft and National Semiconductor which places more 
of the burden on hardware(lntel) and makes for simpler software. Typical 
hardware / software engineer relationship. . . 

With the introduction of USB 2.0 a new Host Controller Interface Specification was 
needed to describe the register level details specific to USB 2.0. The EHCI 
(Enhanced Host Controller Interface) was born. Significant Contributors include 
Intel, Compaq, NEC, Lucent and Microsoft so it would hopefully seem they have 
pooled together to provide us one interface standard and thus only one new driver 
to implement in our operating systems. Its about time. 

USB as its name would suggest is a serial bus. It uses 4 shielded wires of which 
two are power (+5v & GND). The remaining two are twisted pair differential data 
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The loading of the appropriate driver is done using a PID/VID (Product ID/Vendor 
ID) combination. The VID is supplied by the USB Implementor's forum at a cost and 
this is seen as another sticking point for USB. The latest info on fees can be found 
on the USB Implementor's Website 

Other standards organisations provide a extra VID for non-commercial activities 
such as teaching, research or fiddling (The Hobbyist). The USB Implementors 
forum has yet to provide this service. In these cases you may wish to use one 
assigned to your development system's manufacturer. For example most chip 
manufacturers will have a VID/PID combination you can use for your chips which is 
known not to exist as a commercial device. Other chip manufacturers can even sell 
you a PI D to use with their VID for your commercial device. 

Another more notable feature of USB, is its transfer modes. USB supports Control, 
Interrupt, Bulk and Isochronous transfers. While we will look at the other transfer 
modes later, Isochronous allows a device to reserve a defined about of bandwidth 
with guaranteed latency. This is ideal in Audio or Video applications where 
congestion may cause loss of data or frames to drop. Each transfer mode provides 
the designer trade-offs in areas such as error detection and recovery, guaranteed 
latency and bandwidth. 
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USB in a NutShell 

Making sense of the USB standard 



All devices have an upstream connection to the host and all hosts have a 
downstream connection to the device. Upstream and downstream connectors are 
not mechanically interchangeable, thus eliminating illegal loopback connections at 
hubs such as a downstream port connected to a downstream port. There are 
commonly two types of connectors, called type A and type B which are shown 
below. 



1 2 3 4 



2 1 



3 4 



Type A USB Connector 



Type B USB Connector 



Type A plugs always face upstream. Type A sockets will typically find themselves 
on hosts and hubs. For example type A sockets are common on computer main 
boards and hubs. Type B plugs are always connected downstream and 
consequently type B sockets are found on devices. 



It is interesting to find type A to type A cables wired straight through and an array of 
USB gender changers in some computer stores. This is in contradiction of the USB 
specification. The only type A plug to type A plug devices are bridges which are 
used to connect two computers together. Other prohibited cables are USB 
extensions which has a plug on one end (either type A or type B) and a socket on 
the other. These cables violate the cable length requirements of USB. 

USB 2.0 included errata which introduces mini-usb B connectors. The details on 
these connectors can be found in Mini-B Connector Engineering Change Notice 
The reasoning behind the mini connectors came from the range of miniature 
electronic devices such as mobile phones and organisers. The current type B 
connector is too large to be easily integrated into these devices. 

Just recently released has been the Qn-The-Go specification which adds peer-to- 
peer functionality to USB. This introduces USB hosts into mobile phone and 
electronic organisers, and thus has included a specification for mini-A plugs, mini-A 
receptacles, and mini-AB receptacles. I guess we should be inundated with mini 
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USB cables soon and a range of mini to standard converter cables. 



Pin Number 



Cable Colour 



Function 



Red 



V B us ( 5volts ) 



2 



White 



D- 



3 



Green 



D+ 



4 



Black 



Ground 



Standard internal wire colours are used in USB cables, making it easier to identify 
wires from manufacturer to manufacturer. The standard specifies various electrical 
parameters for the cables. It is interesting to read the detail the original USB 1 .0 
spec included. You would understand it specifying electrical attributes, but 
paragraph 6.3.1 .2 suggested the recommended colour for overmolds on USB 
cables should be frost white - how boring! USB 1.1 and USB 2.0 was relaxed to 
recommend Black, Grey or Natural. 

PCB designers will want to reference chapter 6 for standard foot prints and pinouts. 



Unless you are designing the silicon for a USB device/transceiver or USB host/hub, 
there is not all that much you need to know about the electrical specifications in 
chapter 7. We briefly address the essential points here. 

As we have discussed, USB uses a differential transmission pair for data. This is 
encoded using NRZI and is bit stuffed to ensure adequate transitions in the data 
stream. On low and full speed devices, a differential '1' is transmitted by pulling D+ 
over 2.8V with a 15K ohm resistor pulled to ground and D- under 0.3V with a 1 .5K 
ohm resistor pulled to 3.6V. A differential '0' on the other hand is a D- greater than 
2.8V and a D+ less than 0.3V with the same appropriate pull down/up resistors. 

The receiver defines a differential '1 ' as D+ 200mV greater than D- and a 
differential '0' as D+ 200mV less than D-. The polarity of the signal is inverted 
depending on the speed of the bus. Therefore the terms 'J' and 'K' states are used 
in signifying the logic levels. In low speed a 'J' state is a differential 0. In high speed 
a 'J' state is a differential 1 . 

USB transceivers will have both differential and single ended outputs. Certain bus 
states are indicated by single ended signals on D+, D- or both. For example a 
single ended zero or SE0 can be used to signify a device reset if held for more than 
10mS. A SE0 is generated by holding both D- and D+ low (< 0.3V). Single ended 
and differential outputs are important to note if you are using a transceiver and 
FPGA as your USB device. You cannot get away with sampling just the differential 
output. 

The low speed/full speed bus has a characteristic impedance of 90 ohms +/- 15%. 
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It is therefore important to observe the datasheet when selecting impedance 
matching series resistors for D+ and D-. Any good datasheet should specify these 
values and tolerances. 

High Speed (480Mbits/s) mode uses a 17.78mA constant current for signalling to 
reduce noise. 

Speed Identification 

A USB device must indicate its speed by pulling either the D+ or D- line high to 3.3 
volts. A full speed device, pictured below will use a pull up resistor attached to D+ 
to specify itself as a full speed device. These pull up resistors at the device end will 
also be used by the host or hub to detect the presence of a device connected to its 
port. Without a pull up resistor, USB assumes there is nothing connected to the 
bus. Some devices have this resistor built into its silicon, which can be turned on 
and off under firmware control, others require an external resistor. 

For example Philips Semiconductor has a SoftConnect™ technology. When first 
connected to the bus, this allows the microcontroller to initialise the USB function 
device before it enables the pull up speed identification resistor, indicating a device 
is attached to the bus. If the pull up resistor was connected to V b(JS , then this would 

indicate a device has been connected to the bus as soon as the plug is inserted. 
The host may then attempt to reset the device and ask for a descriptor when the 
microprocessor hasn't even started to initialise the usb function device. 

Other vendors such as Cypress Semiconductor also use a programmable resistor 

for Re-Numeration™ purposes in their EzUSB devices where the one device can 
be enumerated for one function such as In field programming then be disconnected 
from the bus under firmware control, and enumerate as another different device, all 
without the user lifting an eyelid. Many of the EzUSB devices do not have any 
Flash or OTP ROM to store code. They are bootstraped at connection. 
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Figure 3 : Low Speed Device with pull up resistor connected to D- 



You will notice we have not included speed identification for High Speed mode. 
High speed devices will start by connecting as a full speed device (1.5k to 3.3V). 
Once it has been attached, it will do a high speed chirp during reset and establish a 
high speed connection if the hub supports it. If the device operates in high speed 
mode, then the pull up resistor is removed to balance the line. 

A USB 2.0 compliant device is not required to support high-speed mode. This 
allows cheaper devices to be produced if the speed isn't critical. This is also the 
case for a low speed USB 1.1 devices which is not required to support full speed. 

However a high speed device must not support low speed mode. It should only 
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support full speed mode needed to connect first, then high speed mode if 
successfully negotiated later. A USB 2.0 compliant downstream facing device (Hub 
or Host) must support all three modes, high speed, full speed and low speed. 

Power (V BUS ) 

One of the benefits of USB is bus-powered devices - devices which obtain its power 
from the bus and requires no external plug packs or additional cables. However 
many leap at this option without first considering all the necessary criteria. 

A USB device specifies its power consumption expressed in 2mA units in the 
configuration descriptor which we will examine in detail later. A device cannot 
increase its power consumption, greater than what it specifies during enumeration, 
even if it looses external power. There are three classes of USB functions, 

o Low-power bus powered functions 
o High-power bus powered functions 
o Self-powered functions 

Low power bus powered functions draw all its power from the V B(JS and cannot 

draw any more than one unit load. The USB specification defines a unit load as 
100mA. Low power bus powered functions must also be designed to work down to 
a V BUS voltage of 4.40V and up to a maximum voltage of 5.25V measured at the 

upsteam plug of the device. For many 3.3V devices, LDO regulators are 
mandatory. 

High power bus powered functions will draw all its power from the bus and cannot 
draw more than one unit load until it has been configured, after which it can then 
drain 5 unit loads (500mA Max) provided it asked for this in its descriptor. High 
power bus functions must be able to be detected and enumerated at a minimum 
4.40V. When operating at a full unit load, a minimum V BUS of 4.75 V is specified 

with a maximum of 5.25V. Once again, these measurements are taken at the 
upstream plug. 

Self power functions may draw up to 1 unit load from the bus and derive the rest of 
it's power from an external source. Should this external source fail, it must have 
provisions in place to draw no more than 1 unit load from the bus. Self powered 
functions are easier to design to specification as there is not so much of an issue 
with power consumption. The 1 unit bus powered load allows the detection and 
enumeration of devices without mains/secondary power applied. 

No USB device, whether bus powered or self powered can drive the V BUS on its 
upstream facing port. If V BUS is lost, the device has a lengthy 10 seconds to 
remove power from the D+/D- pull-up resistors used for speed identification. 

Other V BUS considerations are the Inrush current which must be limited. This is 
outlined in the USB specification paragraph 7.2.4.1 and is commonly overlooked. 
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Inrush current is contributed to the amount of capacitance on your device between 
V BUS and ground. The spec therefore specifies that the maximum decoupling 

capacitance you can have on your device is 10uF. When you disconnect the device 
after current is flowing through the inductive USB cable, a large flyback voltage can 
occur on the open end of the cable. To prevent this, a 1 uF minimum V BUS 

decoupling capacitance is specified. 

For the typical bus powered device, it can not drain any more than 500mA which is 
not unreasonable. So what is the complication you ask? Perhaps Suspend Mode? 

Suspend Current 

Suspend mode is mandatory on all devices. During suspend, additional constrains 
come into force. The maximum suspend current is proportional to the unit load. For 
a 1 unit load device (default) the maximum suspend current is 500uA. This includes 
current from the pull up resistors on the bus. At the hub, both D- and D+ have pull 
down resistors of 15K ohms. For the purposes of power consumption, the pull down 
resistor at the device is in series with the 1 .5K ohms pull up, making a total load of 
16.5K ohms on a V TERM of typically 3.3v. Therefore this resistor sinks 200uA 

before we even start. 

Another consideration for many devices is the 3.3V regulator. Many of the USB 
devices run on 3.3V. The PDIUSBD1 1 is one such example. Linear regulators are 
typically quite inefficient with average quiescent currents in the order of 600uA, 
therefore more efficient and thus expensive regulators are called for. In the majority 
of cases, you must also slow down or stop clocks on microcontrollers to fall within 
the 500uA limit. 

Many developers ask in the USB Implementor's Forum, what are the complications 
of exceeding this limit? It is understood, that most hosts and hubs don't have the 
ability to detect such an overload of this magnitude and thus if you drain maybe 
5mA or even 10mA you should still be fine, bearing in mind that at the end of the 
day, your device violates the USB specification. However in normal operation, if you 
try to exceed the 100mA or your designated permissible load, then expect the hub 
or host to detect this and disconnect your device, in the interest of the integrity of 
the bus. 

Of course these design issues can be avoided if you choose to design a self 
powered device. Suspend currents may not be a great concern for desktop 
computers but with the introduction of the On-The-Go Specification we will start 
seeing USB hosts built into mobile phones and mobile organisers. The power 
consumption pulled from these devices will adversely effect the operating life of the 
battery. 

Entering Suspend Mode 

A USB device will enter suspend when there is no activity on the bus for greater 
than 3.0ms. It then has a further 7ms to shutdown the device and draw no more 
than the designated suspend current and thus must be only drawing the rated 
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suspend current from the bus 10mS after bus activity stopped. In order to maintain 
connected to a suspended hub or host, the device must still provide power to its 
pull up speed selection resistors during suspend. 

USB has a start of frame packet or keep alive sent periodically on the bus. This 
prevents an idle bus from entering suspend mode in the absence of data. 

o A high speed bus will have micro-frames sent every 125.0 us ±62.5 ns. 
o A full speed bus will have a frame sent down each 1 .000 ms ±500 ns. 
o A low speed bus will have a keep alive which is a EOP (End of Packet) every 
1ms only in the absence of any low speed data. 

The term "Global Suspend" is used when the entire USB bus enters suspend mode 
collectively. However selected devices can be suspended by sending a command 
to the hub that the device is connected too. This is referred to as a "Selective 
Suspend." 

The device will resume operation when it receives any non idle signalling. If a 
device has remote wakeup enabled then it may signal to the host to resume from 
suspend. 

Data Signalling Rate 

Another area which is often overlooked is the tolerance of the USB clocks. This is 
specified in the USB specification, section 7.1 .1 1 . 

o High speed data is clocked at 480.00Mb/s with a data signalling tolerance of ± 
500ppm. 

o Full speed data is clocked at 12.000Mb/s with a data signalling tolerance of 

±0.25% or 2,500ppm. 
o Low speed data is clocked at 1 .50Mb/s with a data signalling tolerance of 

±1.5% or 15,000ppm. 

This allows resonators to be used for low cost low speed devices, but rules them 
out for full or high speed devices. 
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USB in a NutShell 

Making sense of the USB standard 

USB Protocols 

Unlike RS-232 and similar serial interfaces where the format of data being sent is 
not defined, USB is made up of several layers of protocols. While this sounds 
complicated, don't give up now. Once you understand what is going on, you really 
only have to worry about the higher level layers. In fact most USB controller I.C.s 
will take care of the lower layer, thus making it almost invisible to the end designer. 

Each USB transaction consists of a 

■ Token Packet (Header defining what it expects to follow), an 

■ Optional Data Packet, (Containing the payload) and a 

■ Status Packet (Used to acknowledge transactions and to provide a 
means of error correction) 

As we have already discussed, USB is a host centric bus. The host initiates all 
transactions. The first packet, also called a token is generated by the host to 
describe what is to follow and whether the data transaction will be a read or write 
and what the device's address and designated endpoint is. The next packet is 
generally a data packet carrying the payload and is followed by an handshaking 
packet, reporting if the data or token was received successfully, or if the endpoint is 
stalled or not available to accept data. 

Common USB Packet Fields 

Data on the USBus is transmitted LSBit first. USB packets consist of the following 
fields, 

■ Sync 

All packets must start with a sync field. The sync field is 8 bits long at 
low and full speed or 32 bits long for high speed and is used to 
synchronise the clock of the receiver with that of the transmitter. The 
last two bits indicate where the PID fields starts. 

> PID 
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PID stands for Packet ID. This field is used to identify the type of packet 
that is being sent. The following table shows the possible values. 



Group 


PID Value 


Packet Identifier 


Token 


0001 


OUT Token 




1001 


IN Token 




0101 


SOF Token 




1101 


SETUP Token 


Data 


0011 


DATA0 




1011 


DATA1 




0111 


DATA2 




1111 


MDATA 


Handshake 


0010 


ACK Handshake 




1010 


NAK Handshake 




A A A C\ 


o i all nanasnaKe 




0110 


NYET (No Response Yet) 


Special 


1100 


PREamble 




1100 


ERR 




1000 


Split 




0100 


Ping 



There are 4 bits to the PID, however to insure it is received correctly, the 
4 bits are complemented and repeated, making an 8 bit PID in total. The 
resulting format is shown below. 

PID PID 1 PID 2 PID 3 nPID nPID 1 nPID 2 nPID 3 

- ADDR 

The address field specifies which device the packet is designated for. 
Being 7 bits in length allows for 127 devices to be supported. Address 
is not valid, as any device which is not yet assigned an address must 
respond to packets sent to address zero. 

- ENDP 
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The endpoint field is made up of 4 bits, allowing 16 possible endpoints. 
Low speed devices, however can only have 2 additional endpoints on 
top of the default pipe. (4 endpoints max) 

- CRC 

Cyclic Redundancy Checks are performed on the data within the packet 
payload. All token packets have a 5 bit CRC while data packets have a 
16 bit CRC. 

. EOP 

End of packet. Signalled by a Single Ended Zero (SEO) for 
approximately 2 bit times followed by a J for 1 bit time. 

USB Packet Types 

USB has four different packet types. Token packets indicate the type of transaction 
to follow, data packets contain the payload, handshake packets are used for 
acknowledging data or reporting errors and start of frame packets indicate the start 
of a new frame. 

■ Token Packets 

There are three types of token packets, 

■ In - Informs the USB device that the host wishes to read 
information. 

> Out - Informs the USB device that the host wishes to send 
information. 

■ Setup - Used to begin control transfers. 

Token Packets must conform to the following format, 

Sync PID ADDR ENDP CRC5 EOP 

> Data Packets 

There are two types of data packets each capable of transmitting up to 
1024 bytes of data. 

■ DataO 

■ Datal 

High Speed mode defines another two data PIDs, DATA2 and MDATA. 
Data packets have the following format, 
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Sync PID 



Data 



CRC16 



EOP 



■ Maximum data payload size for low-speed devices is 8 bytes. 

■ Maximum data payload size for full-speed devices is 1023 bytes. 

■ Maximum data payload size for high-speed devices is 1024 bytes. 

■ Data must be sent in multiples of bytes. 

■ Handshake Packets 

There are three type of handshake packets which consist simply of the 
PID 

■ ACK - Acknowledgment that the packet has been successfully 
received. 

■ NAK - Reports that the device temporary cannot send or received 
data. Also used during interrupt transactions to inform the host 
there is no data to send. 

■ STALL - The device finds its in a state that it requires intervention 
from the host. 

Handshake Packets have the following format, 



> Start of Frame Packets 

The SOF packet consisting of an 1 1-bit frame number is sent by the 
host every 1ms ± 500ns on a full speed bus or every 125 us ± 0.0625 us 
on a high speed bus. 



USB Functions 

When we think of a USB device, we think of a USB peripheral, but a USB device 
could mean a USB transceiver device used at the host or peripheral, a USB Hub or 
Host Controller IC device, or a USB peripheral device. The standard therefore 
makes references to USB functions which can be seen as USB devices which 
provide a capability or function such as a Printer, Zip Drive, Scanner, Modem or 
other peripheral. 

So by now we should know the sort of things which make up a USB packet. No? 
You're forgotten how many bits make up a PID field already? Well don't be too 
alarmed. Fortunately most USB functions handle the low level USB protocols up to 
the transaction layer (which we will cover next chapter) in silicon. The reason why 
we cover this information is most USB function controllers will report errors such as 
PID Encoding Error. Without briefly covering this, one could ask what is a PID 
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Encoding Error? If you suggested that the last four bits of the PID didn't match the 
inverse of the first four bits then you would be right. 




[Addr][Endpoint] [Direction] 



USB Device 



Addr=2 



USB Device 



Addr= 3 



EPO In 



EPO Out 



EP1 In 



EP1 Out 



My Function 



EPO In 



EPO Out 



EP1 In 



EP1 Out 



EP.. In 



EP.. Out 



My Function 



Most functions will have a series of buffers, typically 8 bytes long. Each buffer will 
belong to an endpoint - EPO IN, EPO OUT etc. Say for example, the host sends a 
device descriptor request. The function hardware will read the setup packet and 
determine from the address field whether the packet is for itself, and if so will copy 
the payload of the following data packet to the appropriate endpoint buffer dictated 
by the value in the endpoint field of the setup token. It will then send a handshake 
packet to acknowledge the reception of the byte and generate an internal interrupt 
within the semiconductor/micro-controller for the appropriate endpoint signifying it 
has received a packet. This is typically all done in hardware. 

The software now gets an interrupt, and should read the contents of the endpoint 
buffer and parse the device descriptor request. 

Endpoints 

Endpoints can be described as sources or sinks of data. As the bus is host centric, 
endpoints occur at the end of the communications channel at the USB function. At 
the software layer, your device driver may send a packet to your devices EP1 for 
example. As the data is flowing out from the host, it will end up in the EP1 OUT 
buffer. Your firmware will then at its leisure read this data. If it wants to return data, 
the function cannot simply write to the bus as the bus is controlled by the host. 
Therefore it writes data to EP1 IN which sits in the buffer until such time when the 
host sends a IN packet to that endpoint requesting the data. Endpoints can also be 
seen as the interface between the hardware of the function device and the firmware 
running on the function device. 
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All devices must support endpoint zero. This is the endpoint which receives all of 
the devices control and status requests during enumeration and throughout the 
duration while the device is operational on the bus. 

Pipes 

While the device sends and receives data on a series of endpoints, the client 
software transfers data through pipes. A pipe is a logical connection between the 
host and endpoint(s). Pipes will also have a set of parameters associated with them 
such as how much bandwidth is allocated to it, what transfer type (Control, Bulk, Iso 
or Interrupt) it uses, a direction of data flow and maximum packet/buffer sizes. For 
example the default pipe is a bi-directional pipe made up of endpoint zero in and 
endpoint zero out with a control transfer type. 

USB defines two types of pipes 

o Stream Pipes have no defined USB format, that is you can send any type of 
data down a stream pipe and can retrieve the data out the other end. Data 
flows sequentially and has a pre-defined direction, either in or out. Stream 
pipes will support bulk, isochronous and interrupt transfer types. Stream pipes 
can either be controlled by the host or device. 

o Message Pipes have a defined USB format. They are host controlled, which 
are initiated by a request sent from the host. Data is then transferred in the 
desired direction, dictated by the request. Therefore message pipes allow 
data to flow in both directions but will only support control transfers. 



Chapter 2 : Hardware Chapter 4 : Endpoint Types 

• Connectors 

• Electrical • Control Transfers 

• Speed Identification • Interrupt Transfers 

• Power (Vbus) • Isochronous Transfers 

• Suspend Current • Bulk Transfers 

• Data Signalling Rate 

Comments and Feedback? 



Comments : 
Email Address : 





1 


(Optional) 


Send j 



Copyright 2001 Craig Peacock, 27th June 2003. 
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USB in a NutShell 

Making sense of the USB standard 

USB Descriptors 

All USB devices have a hierarchy of descriptors which describe to the host informat 
as what the device is, who makes it, what version of USB it supports, how many wa 
be configured, the number of endpoints and their types etc 

The more common USB descriptors are 

■ Device Descriptors 

■ Configuration Descriptors 

■ Interface Descr i ptors 

■ E n d point Descriptors 

■ Strin g Descri p tors 

USB devices can only have one device descriptor. The device descriptor includes ir 
such as what USB revision the device complies to, the Product and Vendor IDs use 
the appropriate drivers and the number of possible configurations the device can hs 
number of configurations indicate how many configuration descriptors branches are 

The configuration descriptor specifies values such as the amount of power this parti 
configuration uses, if the device is self or bus powered and the number of interfaces 
When a device is enumerated, the host reads the device descriptors and can make 
of which configuration to enable. It can only enable one configuration at a time. 

For example, It is possible to have a high power bus powered configuration and a s 
powered configuration. If the device is plugged into a host with a mains power supp 
device driver may choose to enable the high power bus powered configuration enat 
device to be powered without a connection to the mains, yet if it is connected to a Is 
personal organiser it could enable the 2nd configuration (self powered) requiring the 
plug your device into the power point. 

The configuration settings are not limited to power differences. Each configuration c 
powered in the same way and draw the same current, yet have different interface oi 
combinations. However it should be noted that changing the configuration requires i 
on each endpoint to stop. While USB offers this flexibility, very few devices have mc 
configuration. 
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Device Descriptor 



bNumConfigurations 



1 




1 


r 


Configuration 




Configuration 


Descriptor 




Descriptor 



bNumlnterfaces 



bNum Interfaces 





Interface 






Descriptor 








bNumEndpoints 




r 






I 


Endpoint 




Endpoint 


Descriptor 




Descriptor 



Interface 
Descriptor 



|bNumEn dpoints 



1 


1 


1 




Endpoint 




Endpoint 


Descriptor 




Descriptor 



Interface 
Descriptor 



{bNumEndpoints 



1 


1 


1 




Endpoint 




Endpoint 


Descriptor 




Descriptor 



Interf* 
Descrif 



Endpoint 
Descriptor 



The interface descriptor could be seen as a header or grouping of the endpoints int< 
functional group performing a single feature of the device. For example you could h 
multi-function fax/scanner/printer device. Interface descriptor one could describe th< 
of the fax function, Interface descriptor two the scanner function and Interface desci 
the printer function. Unlike the configuration descriptor, there is no limitation as to h; 
one interface enabled at a time. A device could have 1 or many interface descriptor 
at once. 



Interface descriptors have a blnterfaceNumber field specifying the Interface numb< 
bAlternateSetting which allows an interface to change settings on the fly. For exan 
could have a device with two interfaces, interface one and interface two. Interface o 
blnterfaceNumber set to zero indicating it is the first interface descriptor and a 
bAlternativeSetting of zero. 

Interface two would have a blnterfaceNumber set to one indicating it is the second 
and a bAlternativeSetting of zero (default). We could then throw in another descri|: 
with a blnterfaceNumber set to one indicating it is the second interface, but this tin 
the bAlternativeSetting to one, indicating this interface descriptor can be an altern 
setting to that of the other interface descriptor two. 

When this configuration is enabled, the first two interface descriptors with 
bAlternativeSettings equal to zero is used. However during operation the host car 
Setlnterface request directed to that of Interface one with a alternative setting of on< 
the other interface descriptor. 
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Configuration Descriptor 



Interface Zero D escriptor, bAlternateSetting = 








Endpoint Descriptor One 


Endpoint Descriptor Two 



Interface One Descriptor, b Alte m ate S etti n g = 



Endpoint Descriptor One 



Endpoint Descriptor Two 



Interface One Descriptor, bAlte rn ate S etti n g = 1 



Endpoint Descriptor One 



Endpoint Descriptor Tmio 



(Interrupt Pipes) 



(Bulk Pipes) 



This gives an advantage over having two configurations, in that we can be transmitt 
over interface zero while we change the endpoint settings associated with interface 
without effecting interface zero. 

Each endpoint descriptor is used to specify the type of transfer, direction, polling int 
maximum packet size for each endpoint. Endpoint zero, the default control endpoinl 
assumed to be a control endpoint and as such never has a descriptor. 

Composition of USB Descriptors 

All descriptors are made up of a common format. The first byte specifies the length 
descriptor, while the second byte indicates the descriptor type. If the length of a des 
smaller than what the specification defines, then the host shall ignore it. However if 
greater than expected the host will ignore the extra bytes and start looking for the m 
descriptor at the end of actual length returned. 



Offset 

o 
1 

2 



Field 
bLength 
bDescriptionType 



Size Value Description 

1 Number Size of Descriptor in Bytes 

1 Constant DescriptorType 

n Start of parameters for descriptor 



Device Descriptors 

The device descriptor of a USB device represents the entire device. As a result a U 
can only have one device descriptor. It specifies some basic, yet important informat 
the device such as the supported USB version, maximum packet size, vendor and f 
and the number of possible configurations the device can have. The format of the d 
descriptor is shown below. 



Offset 



Field 



Size 



Value 



Description 
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bLength 1 Number Size of the Descriptor in Bytes (18 bytes) 

1 bDescriptorType 1 Constant Device Descriptor (0x01) 

2 bcdUSB 2 BCD USB Specification Number which device < 

too. 

4 bDeviceClass 1 Class Class Code (Assigned by USB Org) 



If equal to Zero, each interface specifies i 
class code 

If equal to OxFF, the class code is vendor 
specified. 

Otherwise field is valid Class Code. 



5 bDeviceSubClass 1 Subclass Subclass Code (Assigned by USB Org) 

6 bDeviceProtocol 1 Protocol Protocol Code (Assigned by USB Org) 

7 bMaxPacketSize 1 Number Maximum Packet Size for Zero Endpoint. 

Sizes are 8, 16, 32, 64 

8 idVendor 2 ID Vendor ID (Assigned by USB Org) 

10 idProduct 2 ID Product ID (Assigned by Manufacturer) 

12 bcdDevice 2 BCD Device Release Number 

14 iManufacturer 1 Index Index of Manufacturer String Descriptor 

15 iProduct 1 Index Index of Product String Descriptor 

16 iSerialNumber 1 Index Index of Serial Number String Descriptor 

17 bNumConfigurations 1 Integer Number of Possible Configurations 



■ The bcdUSB field reports the highest version of USB the device supports. Th 
in binary coded decimal with a format of OxJJMN where J J is the major versioi 
M is the minor version number and N is the sub minor version number, e.g. U, 
reported as 0x0200, USB 1. 1 as 0x01 10 and USB 1.0 as 0x0100. 

■ The bDeviceClass, bDeviceSubClass and bDeviceProtocol are used by thi 
system to find a class driver for your device. Typically only the bDeviceClass i 
device level. Most class specifications choose to identify itself at the interface 
as a result set the bDeviceClass as 0x00. This allows for the one device to su, 
multiple classes. 

• The bMaxPacketSize field reports the maximum packet size for endpoint zeri 
devices must support endpoint zero. 

• The idVendor and idProduct are used by the operating system to find a drivt 
device. The Vendor ID is assigned by the USB-IF. 
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> The bcdDevice has the same format than the bcdUSB and is used to provide 
version number. This value is assigned by the developer. 

m Three string descriptors exist to provide details of the manufacturer, product a 
number. There is no requirement to have string descriptors. If no string descrii 
present, a index of zero should be used. 

m bNumConfigurations defines the number of configurations the device suppo, 
current speed. 

Configuration Descriptors 

A USB device can have several different configurations although the majority of dev 
simple and only have one. The configuration descriptor specifies how the device is | 
what the maximum power consumption is, the number of interfaces it has. Therefon 
possible to have two configurations, one for when the device is bus powered and ar 
when it is mains powered. As this is a "header" to the Interface descriptors, its also 
have one configuration using a different transfer mode to that of another configurath 

Once all the configurations have been examined by the host, the host will send a 
SetConfiguration command with a non zero value which matches the bConfiguratioi 
one of the configurations. This is used to select the desired configuration. 



Offset Field Size Value Description 

bLength 1 Number Size of Descriptor in Bytes 

1 bDescriptorType 1 Constant Configuration Descriptor (0x02) 

2 wTotalLength 2 Number Total length in bytes of data returned 

4 bNumlnterfaces 1 Number Number of Interfaces 

5 bConfigurationValue 1 Number Value to use as an argument to select this 

configuration 

6 iConfiguration 1 Index Index of String Descriptor describing this 

configuration 

7 bmAttributes 1 Bitmap D7 Reserved, set to 1 . (USB 1 .0 Bus Pow< 

D6 Self Powered 
D5 Remote Wakeup 
D4..0 Reserved, set to 0. 

8 bMaxPower 1 mA Maximum Power Consumption in 2mA uni 



■ When the configuration descriptor is read, it returns the entire configuration hit 
which includes all related interface and endpoint descriptors. The wTotalLenc 
reflects the number of bytes in the hierarchy. 
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Device Descriptor 



Configuration Descriptor One 



+■ I nte rf a ce Ze ro D escri pto r 



Endpoint Descriptor One 



Endpoint Descriptor Two 



Interface One Descriptor 



Endpoint Descriptor One 



Endpoint Descriptor Two 



■*■ Configuration Descriptor Two 



*■ I nte rf a ce Ze ro D escri pto r 



HID Descriptor 



Endpoint Descriptor One 



Configurati on D escri p 
->wTota I Length 



Configuration Descrip 
->wTota I Length 



■ bNumlnterfaces specifies the number of interfaces present for this configurat 

m bConfigurationValue is used by the SetConfiguration request to select this 
configuration. 

• iConfiguration is a index to a string descriptor describing the configuration in 
readable form. 



m bm Attributes specify power parameters for the configuration. If a device is se 
powered, it sets D6. Bit D7 was used in USB 1.0 to indicate a bus powered de 
this is now done by bMaxPower. If a device uses any power from the bus, wht 
as a bus powered device or as a self powered device, it must report its power 
consumption in bMaxPower. Devices can also support remote wakeup which 
device to wake up the host when the host is in suspend. 

m bMaxPower defines the maximum power the device will drain from the bus. 7 
2mA units, thus a maximum of approximately 500mA can be specified. The sr. 
allows a high powered bus powered device to drain no more than 500mA fron 
device loses external power, then it must not drain more than indicated in bMe 
should fail any operation it cannot perform without external power. 

Interface Descriptors 

The interface descriptor could be seen as a header or grouping of the endpoints int< 
functional group performing a single feature of the device. The interface descriptor ( 
the following format, 
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Offset 


Field Size 


Value 


Description 





bLength 1 


Number 


Size of Descriptor in Bytes (9 Bytes) 


1 


bDescriptorType 1 


Constant 


Interface Descriptor (0x04) 


2 


blnterfaceNumber 1 


Number 


Number of Interface 


3 


bAlternateSetting 1 


Number 


Value used to select alternative setting 


4 


bNumEndpoints 1 


Number 


Number of Endpoints used for this interfac 


5 


blnterfaceClass 1 


Class 


Class Code (Assigned by USB Org) 


6 


blnterfaceSubClass 1 


Subclass 


Subclass Code (Assigned by USB Org) 


7 


blnterfaceProtocol 1 


Protocol 


Protocol Code (Assigned by USB Org) 


8 


ilnterface 1 


Index 


Index of String Descriptor Describing this ii 



■ blnterfaceNumber indicates the index of the interface descriptor. This should 
based, and incremented once for each new interface descriptor. 

m bAlternativeSetting can be used to specify alternative interfaces . These altei 
interfaces can be selected with the Set Interface request. 

* bNumEndpoints indicates the number of endpoints used by the interface. Th 
should exclude endpoint zero and is used to indicate the number of endpoint i 
to follow. 

m blnterfaceClass, blnterfaceSubClass and blnterfaceProtocol can be used 
supported classes (e.g. HID, communications, mass storage etc.) This allows 
devices to use class drivers preventing the need to write specific drivers foryc 

• ilnterface allows for a string description of the interface. 

Endpoint Descriptors 

Endpoint descriptors are used to describe endpoints other than endpoint zero. Endf 
is always assumed to be a control endpoint and is configured before any descriptor 
requested. The host will use the information returned from these descriptors to dete 
bandwidth requirements of the bus. 

Offset Field Size Value Description 



bLength 1 Number Size of Descriptor in Bytes (7 bytes) 

1 bDescriptorType 1 Constant Endpoint Descriptor (0x05) 

2 bEndpointAddress 1 Endpoint Endpoint Address 

Bits 0..3b Endpoint Number. 
Bits 4. .6b Reserved. Set to Zero 
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Bits 7 Direction = Out, 1 = In (Ignored fc 
Endpoints) 

3 bmAttributes 1 Bitmap Bits 0..1 Transfer Type 

00 = Control 

01 = Isochronous 

10 = Bulk 

1 1 = Interrupt 

Bits 2.7 are reserved. If Isochronous end 
Bits 3. .2 = Synchronisation Type (Iso Moc 

00 = No Synchonisation 

01 = Asynchronous 

1 = Adaptive 

1 1 = Synchronous 

Bits 5.. 4 = Usage Type (Iso Mode) 

00 = Data Endpoint 

01 = Feedback Endpoint 

10 = Explicit Feedback Data Endp< 

1 1 = Reserved 

4 wMaxPacketSize 2 Number Maximum Packet Size this endpoint is ca| 

sending or receiving 

6 blnterval 1 Number Interval for polling endpoint data transfers 

frame counts. Ignored for Bulk & Control 
Endpoints. Isochronous must equal 1 and 
may range from 1 to 255 for interrupt end 

■ bEndpointAddress indicates what endpoint this descriptor is describing. 

m bmAttributes specifies the transfer type. This can either be Control , Interrupt, 
Isochronous or Bulk Transfers . If an Isochronous endpoint is specified, additic 
attributes can be selected such as the Synchronisation and usage types. 

• wMaxPacketSize indicates the maximum payload size for this endpoint. 

• blnterval is used to specify the polling interval of certain transfers. The units e 
expressed in frames, thus this equates to either 1ms for low/full speed devicei 
125us for high speed devices. 

String Descriptors 

String descriptors provide human readable information and are optional. If they are 
any string index fields of descriptors must be set to zero indicating there is no string 
available. 

The strings are encoded in the Unicode format and products can be made to suppo 
languages. String Index should return a list of supported languages. A list of USB 
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IDs can be found in U nivers al Serial Bus Langua g e Identifiers (LANGIDs) version 1 



Offset Field Size 

bLength 1 

1 bDescriptorType 1 

2 wLANGID[0] 2 

4 wLANGID[1] 2 

n wLANGID[x] 2 



Value Description 

Number Size of Descriptor in Bytes 

Constant String Descriptor (0x03) 

number Supported Language Code Zero 

(e.g. 0x0409 English - United States) 

number Supported Language Code One 
(e.g. 0x0c09 English - Australian) 

number Supported Language Code x 

(e.g. 0x0407 German - Standard) 



The above String Descriptor shows the format of String Descriptor Zero. The host s 
this descriptor to determine what languages are available. If a language is supporte 
then be referenced by sending the language ID in the wlndex field of a Get Descripl 
request. 

All subsequent strings take on the format below, 



Offset Field 

bLength 

1 bDescriptorType 

2 bString 



Size Value Description 

1 Number Size of Descriptor in Bytes 

1 Constant String Descriptor (0x03) 

n Unicode Unicode Encoded String 



Chapter 4 : Endpoint Types 
• Control Transfers 



• Interrupt Tr ansf ers 

• I so c hronous Transfers 

• Bulk tr ansfers 



Comments : 
Email Address : 



Chapter 6 : USB Requests 



• T he Setup Packet 

• Standard Device Requests 

• Standard Interface Requests 

• Standard Endpoint Requests 

Comments and Feedback? 



(Optional) Send | 



Copyright 2002 Craig Peacock, 27th June 2003. 
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Making sense of the USB standard 

The Setup Packet 

Every USB device must respond to setup packets on the default pipe. The setup pa 
used for detection and configuration of the device and carry out common functions j 
setting the USB device's address, requesting a device descriptor or checking the st; 
endpoint. 

A USB compliant Host expects all requests to be processed within a maximum perk 
seconds. It also specifies stricter timing for specific requests : 

■ Standard Device requests without a data stage must be completed in 50ms. 

■ Standard Device requests with a data stage must start to return data 500ms a 
request. 

> Each data packet must be sent within 500ms of the successful transmis; 
previous packet. 

> The status stage must complete within 50ms after the transmission of th 
packet. 

■ The SetAddress command (which contains a data phase) must process the cc 
return status within 50ms. The device then has 2ms to change address before 
request is sent. 

These timeout periods are quite acceptable for even the slowest of devices, but car 
restriction during debugging. 50mS doesn't provide for many debugging characters 
9600bps on an asynchronous serial port or for a In Circuit Debugger/Emulator to sir 
to break execution to examine the internal Registers. As a result, USB requires son 
debugging methods to that of other microcontroller projects. 

Casually reading through the XP DDK, one may note the Host Controller Drivt 
USBUSER_OP_SEND_ONE_PACKET command which is commented to rea 
is used to implement the 'single step' USB transaction development tool." Whi 
tool has not been released yet, we can only hope to see one soon. 

Each request starts with a 8 byte long Setup Packet which has the following format, 
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Offset Field Size 

bmRequestType 1 



Value 
Bit-Map 



1 

2 



bRequest 
wValue 

wlndex 
wLength 



1 
2 



Value 

Value 

Index or 
Offset 

Count 



Description 

D7 Data Phase Transfer Direction 

= Host to Device 

1 = Device to Host 
D6..5 Type 

= Standard 

1 = Class 

2 = Vendor 

3 = Reserved 
D4..0 Recipient 

= Device 

1 = Interface 

2 = Endpoint 

3 = Other 

4.. 31 = Reserved 

Request 
Value 

Index 

Number of bytes to transfer if there is 
a data phase 



The bmRequestType field will determine the direction of the request, type of reque 
designated recipient. The bRequest field determines the request being made. The 
bmRequestType is normally parsed and execution is branched to a number of hand 
a Standard Device request handler, a Standard Interface request handler, a Standa 
request handler, a Class Device request handler etc. How you parse the setup pacl< 
up to your preference. Others may choose to parse the bRequest first and then det< 
type and recipient based on each request. 

Standard requests are common to all USB devices and are detailed in the next com 
Class requests are common to classes of drivers. For example, all device conformir 
class will have a common set of class specific requests. These will differ to a device 
to the communications class and differ again to that of a device conforming to the it 
class. 

And last of all is the vendor defined requests. These are requests which you as the 
designer can assign. These are normally different from device to device, but this is ; 
implementation and imagination. 

A common request can be directed to different recipients and based on the recipien 
different functions. A GetStatus Standard request for example, can be directed at th 
interface or endpoint. When directed to a device it returns flags indicating the status 
wakeup and if the device is self powered. However if the same request is directed a 
interface it always returns zero, or should it be directed at an endpoint will return the 
the endpoint. 

The wValue and wlndex fields allow parameters to be passed with the request. wL 
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used the specify the number of bytes to be transferred should there be a data phas< 
Standard Requests 

Section 9.4 of the USB specification details the "Standard Device" requests requirec 
implemented for every USB device. The standard provides a single table grouping i 
request. Considering most firmware will parse the setup packet by recipient we will i 
up the requests based by recipient for easier examination and implementation. 

Standard Device Requests 

There are currently eight Standard Device requests, all of which are detailed in the 1 



bmRequestType 



bRequest 



wValue 



wlndex wLength 



1000 0000b 



GET_STATUS (0x00) 



Zero 



Zero 



Two 



0000 0000b 



0000 0000b 



1000 0000b 

0000 0000b 

1000 0000b 
0000 0000b 



CLEARFEATURE 
(0x01) 

SET FEATURE (0x03) 



0000 0000b SET ADDRESS (0x05) 



Feature 
Selector 

Feature 
Selector 

Device 
Address 



GET_DESCRIPTOR Descriptor 
(0x06) Type & Index 



SET_DESCRIPTOR Descriptor 
(0x07) Type & Index 



GETCONFIGURATION 

(0x08) 



Zero 



SETCONFIGURATION Configuration 
(0x09) Value 



Zero 



Zero 



Zero 

Zero or 
Language 
ID 

Zero or 
Language 
ID 

Zero 



Zero 



Zero 
Zero 
Zero 



Descriptor 
Length 



Descriptor 
Length 



r. 

Cc 



Zero 



The Get Status request directed at the device will return two bytes during the 
with the following format, 



D15 D14 D13 D12 D1 1 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 



If DO is set, then this indicates the device is self powered. If clear, the device i 
powered. IfDIis set, the device has remote wakeup enabled and can wake tl 
during suspend. The remote wakeup bit can be by the SetFeature and ClearF 
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requests with a feature selector of DEVICE_REMOTE_WAKEUP (0x01) 

■ Clear Feature and Set Feature requests can be used to set boolean features 
designated recipient is the device, the only two feature selectors available are 
DEVICE_REMO TE_ WA KE UP and TEST MODE. Test mode allows the devic 
various conditions. These are further documented in the USB Specification Re 

■ Set Address is used during enumeration to assign a unique address to the U- 
The address is specified in wValue and can only be a maximum of 127. This r 
unique in that the device does not set its address until after the completion of 
stage. (See Control Transfers.) All other requests must complete before the si 

• Set Descriptor/Get Descriptor is used to return the specified descriptor in w' 
request for the configuration descriptor will return the device descriptor and ah 
and endpoint descriptors in the one request. 

m Endpoint Descriptors cannot be accessed directly by a GetDescriptor/Se 
Request. 

• Interface Descripto rs cannot be accessed directly by a GetDescriptor/Se 
Request. 

• Str in g Descriptors include a Language ID in wlndex to allow for multiple 
support. 

m Get Configuration/Set Configuration is used to request or set the current de 
configuration. In the case of a Get Configuration request, a byte will be returm 
data stage indicating the devices status. A zero value means the device is not 
and a non-zero value indicates the device is configured. Set Configuration is l 
enable a device. It should contain the value of bConfigurationValue of the des 
configuration descriptor in the lower byte of wValue to select which configurati 

Standard Interface Requests 

The specification current defines five Standard Interface requests which are detaile< 
below. Interestingly enough, only two requests do anything intelligible. 



bmRequestType 
1000 0001b 

0000 0001b 

0000 0001b 

1000 0001b 

0000 0001b 



bRequest 



wValue 



GET STATUS (0x00) Zero 



CLEARFEATURE 
(0x01) 

SETFEATURE 

(0x03) 

GETINTERFACE 
(OxOA) 

SETJNTERFACE 
(0x11) 



Feature 
Selector 

Feature 
Selector 

Zero 

Alternative 
Setting 



wlndex 
Interface 

Interface 

Interface 

Interface 

Interface 



wLength 
Two 

Zero 

Zero 

One 

Zero 
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> wlndex is normally used to specify the referring interface for requests directec 
interface. Its format is shown below. 

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 
Reserved Interface Number 

■ Get Status is used to return the status of the interface. Such a request to the 
should return two bytes of 0x00, 0x00. (Both bytes are reserved for future use 

• Clear Feature and Set Feature requests can be used to set boolean features 
designated recipient is the interface, the current USB Specification Revision 2 
interface features. 

• Get Interface and Set Interface set the Alternative Interface setting which is < 
more detail under the Interface Descriptor . 

Standard Endpoint Requests 

Standard Endpoint requests come in the four varieties listed below. 



bmRequestType 



bRequest 



1000 0010b GET STATUS (0x00) 



0000 0010b 
0000 0010b 
1000 0010b 



CLEARFEATURE 
(0x01) 

SETFEATURE 

(0x03) 

SYNCHFRAME 
(0x12) 



wValue 

Zero 

Feature 
Selector 

Feature 
Selector 

Zero 



Windex wLength 
Endpoint Two 



Endpoint 



Endpoint 



Endpoint 



Zero 



Zero 



Two Frai 



The wlndex field is normally used to specify the referring endpoint and directit 
requests directed to an endpoint. Its format is shown below. 

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 
Reserved Dir Reserved Endpo 

Get Status returns two bytes indicating the status (Halted/Stalled) of a endpoi 
format of the two bytes returned is illustrated below. 

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 

Reserved 
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■ Clear Feature and Set Feature are used to set Endpoint Features. The stand 
defines one endpoint feature selector, ENDPOINT_HAL T (0x00) which allows 
stall and clear an endpoint. Only endpoints other than the default endpoint is 
recommended to have this functionality. 

m A Synch Frame request is used to report an endpoint synchronisation frame. 



Chapter 5 : USB Descriptors Chapter 7 : Example Firmwa 

• Device Descriptors 

• Configuration Descriptors • Enumeration 

• Interface Descriptors • Firmware Example - PDIUSBD1 

• Endpoint Des criptors • Sou rce Code 

• String Descriptors 
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CONGRATULATIONS! YOU'VE WON! 



You are visitor #857336 to this site 




Fr 



Universal Serial Bus Embedded Internet Legacy Ports Device Drivers Miscellaneou 



Making Sense of the USB Standard 

Enumeration 

Enumeration is the process of determining what device has just been connected to 
it requires such as power consumption, number and type of endpoint(s), class of pr< 
assign the device an address and enable a configuration allowing the device to tran 
generic enumeration process is detailed in section 9.1.2 of the USB specification. H 
firmware for the first time, it is handy to know exactly how the host responds during 
general enumeration process detailed in the specification. 

A common Windows enumeration involves the following steps, 

1 . The host or hub detects the connection of a new device via the device's pull u 



The host waits for at least 100ms allowing for the plug to be inserted fully and 



2. Host issues a reset placing the device is the default state. The device may no 
address zero. 

3. The MS Windows host asks for the first 64 bytes of the Device Descriptor. 

4. After receiving the first 8 bytes of the Device Descriptor, it immediately issues 

5. The host now issues a Set Address command, placing the device in the addre 

6. The host asks for the entire 1 8 bytes of the Device Descriptor. 

7. It then asks for 9 bytes of the Configuration Descriptor to determine the overal 

8. The host asks for 255 bytes of the Configuration Descriptor. 

9. Host asks for any String Descriptors if they were specified. 

At the end of Step 9, Windows will ask for a driver for your device. It is then commo 
descriptors again before it issues a Set Configuration request. 

The above enumeration process is common to Windows 2000, Windows XP and W 



USB in a NutShell 



device. 
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Step 4 often confuses people writing firmware for the first time. The Host asks for th 
descriptor, so when the host resets your device after it receives the first 8 bytes, it h 
something wrong with your device descriptor or how your firmware handles the reqi 
tell you, if you keep persisting by implementing the Set Address Command it will pa 
bytes of device descriptor next. 

Normally when something is wrong with a descriptor or how it is being sent, the hos 
times with long pauses in between requests. After the third attempt, the host gives i 
device. 

Firmware - PIC16F876 controlling the PDIUSBD11 

We start our examples with a Philip's PDIUSBD1 1 I2C Serial USB Device connecte 
(shown) or a Microchip PIC16F877 (Larger 40 Pin Device). While Microchip has gol 
PIC16C745 and PIC16C765 devices out now, they are only OTP without In-Circuit I 
which doesn't help with the development flow too well. They do have four new full si 
support coming. In the mean time the Philips PDIUSBD11 connected to the PIC16F 
advantage of Flash and In-Circuit Debugging. 
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tea 
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03)1 


vm 


0S2 





Click here to enlarge 



A schematic of the required hardware is shown above. The example enumerates ar 
be read from the five multiplexed ADC inputs on the PIC16F876 MCU. The code is 
PIC16F877 allowing a maximum of 8 Analog Channels. A LED connected on port p 
is configured. A 3.3V regulator is not pictured, but is required for the PDIUSBD1 1 . II 
circuit from an external power supply, then you can use a garden variety 78L033 3.: 
if you wish to run the device as a Bus Powered USB device then a low dropout regi 

Debugging can be done by connecting TXD (Pin 17) to a RS-232 Line Driver and fe 
Printf statements have been included which display the progress of enumeration. 

The code has been written in C and compiled with the Hi-Tech PICC Compiler . The 
PL4) of the PICC for download which works for 30 days. A pre-compiled .HEX file h 
which has been compiled for use with (or without) the ICD. 
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#include <pic.h> 
#include <stdio.h> 
#include <string.h> 
#include "usbfull.h" 



const USB_DEVICE_DESCRIPTOR DeviceDescriptor = { 



sizeof (USB_DEVICE_DESCRIPTOR) , 


/* 


bLength */ 




TYPE_DEVICE_DESCRIPTOR, 


/* 


bDescriptorType */ 




0x0110, 


/* 


bcdUSB USB Version 1.1 */ 




0, 


/* 


bDeviceClass */ 




o, 


/* 


bDeviceSubclass */ 




o, 


/* 


bDeviceProtocol */ 




8, 


/* 


bMaxPacketSize 8 Bytes */ 




0x04B4 , 


/* 


idVendor (Cypress Semi) */ 




0x0002 , 


/* 


idProduct (USB Thermometer 


Example 


0x0000 , 


/* 


bcdDevice */ 




1, 


/* 


iManuf acturer String Index 


*/ 


o, 


/* 


iProduct String Index */ 




o, 


/* 


iSerialNumber String Index 


*/ 


1 


/* 


bNumberConf igurations */ 





The structures are all defined in the header file. We have based this example on th€ 
example so you can use our U SB Driver for the Cypress USB Starter Kit . A new get 
support this and other examples which will be available soon. Only one string is pro 
manufacturer. This gives enough information about how to implement string descrip 
entire device with code. A description of the Device Descriptor and its fields can be 



const USB_CONFIG_DATA Conf igurationDescriptor = { 

{ /* configuration descriptor 

sizeof (USB_CONFIGURATION_DESCRIPTOR) , /* bLength */ 



7 



TYPE_CONFIGURATION_DESCRIPTOR, 

sizeof ( US B_CONF I G_D AT A ) , 

1, 

1, 

0, 

0x80, 
0x32 



/* 
/* 
/* 
/* 
/* 
/* 
/* 

/* 



7 



{ 

sizeof ( USB_INTERFACE_DES CRI PTOR ) , 

TYPE_INTERFACE_DESCRIPTOR, /* 

0, /* 

0, /* 

2, /* 

OxFF, /* 

OxFF, /* 

OxFF, /* 

/* 

{ /* 
sizeof (USB_ENDPOINT_DESCRIPTOR) , 

TYPE_ENDPOINT_DESCRIPTOR, /* 

0x01, /* 

0x02, /* 

0x0008, /* 

0x00 /* 

}. 



7 



bDescriptorType 
wTotalLength */ 
bNumlnterf aces */ 
bConf igurat ion Value 
iConf iguration String Index */ 
bmAttributes Bus Powered, No Remote 
bMaxPower, 100mA */ 

interface descriptor */ 
/* bLength */ 
bDescriptorType */ 
blnterface Number */ 
bAlternateSetting */ 
bNumEndpoints */ 

blnterf aceClass (Vendor specific) */ 
blnterf aceSubClass */ 
blnterf aceProtocol */ 
ilnterface String Index 



7 



7 



endpoint descriptor 
/* bLength */ 
bDescriptorType */ 
bEndpoint Address EP1 OUT */ 
bmAttributes - Interrupt */ 
wMaxPacketSize */ 
blnterval */ 
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}; 



{ /* 

sizeof (USB_ENDPOINT_DESCRIPTOR) , 

TYPE_ENDPOINT_DESCRIPTOR, /* 

0x81, /* 

0x02, /* 

0x0008, /* 

0x00 /* 
} 



endpoint descriptor */ 
/* bLength */ 
bDescriptorType */ 
bEndpoint Address EPl IN 
bmAttributes - Interrupt 
wMaxPacketSize */ 
binterval */ 



*/ 
*/ 



A description of the Configuration Descriptor and its fields can be found here. We pi 
descriptors on top of the default pipe. EP1 OUT is an 8 byte maximum Bulk OUT Er 
byte max Bulk IN Endpoint. Our example reads data from the Bulk OUT endpoint ar 
circular buffer. Sending an IN packet to EP1 reads 8 byte chunks from this circular I 



LANG ID_DE S CR I PTOR LANGID_Descriptor 
sizeof (LANGID_DESCRIPTOR) , 
TYPE_STRING_DESCRIPTOR, 
0x0409 

}; 



{ /* LANGID String Descriptor Zero * 

/* bLenght */ 

/* bDescriptorType */ 

/* LANGID US English */ 



const MANUFACTURER_DE S CR I PTOR Manuf acturer_Descriptor 
sizeof ( MANUFACTURER_DES CRI PTOR ) , 
TYPE_STRING_DESCRIPTOR, 

"B\0e\0y\0o\0n\0d\0 \0L\0o\0g\0i\0c\0 " 

}; 



{ /* Manufacturers 
/* bLenght */ 
/* bDescriptorT} 
/ * Manufacturers 



A Zero Index String Descriptor is provided to support the LANGID requirements of I 
indicates all descriptors are in US English. The Manufacturer Descriptor can be a lit 
the char array is fixed in the header and is not dynamic. 



#define MAX BUFFER SIZE 80 



bankl unsigned char circularbuf f er [MAX_BUFFER_SIZE] ; 
unsigned char inpointer; 
unsigned char outpointer; 

unsigned char *pSendBuf f er ; 
unsigned char BytesToSend; 
unsigned char CtlTransf erlnProgress ; 
unsigned char DeviceAddress ; 
unsigned char DeviceConf igured; 



#define PROGRES S_IDLE 
#define PROGRESS ADDRESS 




3 



void main (void) 
{ 

TRISB = 0x03; /* Int & Suspend Inputs */ 

RB3 =1; /* Device Not Configured (LED) */ 

RB2 =0; /* Reset PDIUSBD11 */ 

InitUARTO ; 

printf ( "Initialising\n\r" ) ; 
I2C_Init () ; 



RB2 = 1; 



/* Bring PDIUSBD11 out of reset */ 
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ADC0N1 = 0x80; /* ADC Control - All 8 Channels Enabled, */ 
/* supporting upgrade to 16F877 */ 

USB_Init ( ) ; 

printf ( "PDIUSBD11 Ready for connection\n\r" ) ; 
while (1) 

if (!RB0) DllGetlRQ () ; /* If IRQ is Low, PDIUSBD11 has an Interrup 

} 

The main function is example dependent. It's responsible for initialising the directior 
the I2C interface, Analog to Digital Converters and PDIUSBD1 1 . Once everything is 
D11GetlRQ which processes PDIUSBD1 1 Interrupt Requests. 

void USB_Init (void) 
{ 

unsigned char Buffer [2]; 

/* Disable Hub Function in PDIUSBD11 */ 
Buffer [0] = 0x00; 

DllCmdDataWrite (D11_SET_HUB_ADDRESS , Buffer, 1) ; 

/* Set Address to zero (default) and enable function */ 
Buffer [0] = 0x80; 

DllCmdDataWrite (D11_SET_ADDRESS_ENABLE, Buffer, 1) ; 

/* Enable function generic endpoints */ 
Buffer [0] = 0x02; 

DllCmdDataWrite (Dll_SET_ENDPOINT_ENABLE, Buffer, 1) ; 
/* Set Mode - Enable SoftConnect */ 

Buffer [0] = 0x97; /* Embedded Function, SoftConnect, Clk Run, No LazyC 
Buffer [1] = OxOB; /* CLKOut = 4MHz */ 
DllCmdDataWrite (Dll_SET_MODE, Buffer, 2); 

} 

The USB Init function initialises the PDIUSBD11. This initialisation procedure has b< 
PDIUSBD1 1 datasheet but is available from their FAQ . The last command enables 
resistor on D+ indicating it is a full speed device but also advertises its presence on 

void DllGetlRQ (void) 
{ 

unsigned short Irq; 
unsigned char Buffer [1] ; 

/* Read Interrupt Register to determine source of interrupt */ 

D 1 1 CmdDa t aRe ad ( D 1 1_RE AD_I NTERRUPT_REG I STER , (unsigned char *)&Irq, 

if (Irq) printf ("Irq = 0x%X: " , Irq) ; 

Main() keeps calling the DllGetlRQ in a loop. This function reads the PDIUSBD1 1' 
establish if any interrupts are pending. If this is the case it will act upon them, otherv 
Other USB devices may have a series of interrupt vectors assigned to each endpoir 
service the appropriate interrupt removing the if statements. 



http://www.beyondlogic.org/usbnutshell/usb7.htm 



02/07/2004 



USB in a NutShell - Chapter 7 - PDIUSBD1 1 and PIC16F87x Example 



Page 6 of 17 



if (Irq & D11_INT_BUS_RESET) { 
printf("Bus Reset\n\r" ) ; 
USB_Init () ; 

} 

if (Irq & Dll_INT_EP0_OUT) { 
print f ("EP0_Out: ") ; 
Process_EPO_OUT_Interrupt ( ) ; 

} 

if (Irq & D11_INT_EP0_IN) { 
printf ("EP0_In: \n\r"); 

if (CtlTransf erlnProgress == PROGRESS_ADDRESS) { 

DllCmdDataWrite (D11_SET_ADDRESS_ENABLE, &DeviceAddress, 1) ; 
D 1 1 CmdDa t aRe ad ( D 1 1_RE AD_L AS T_TRANS ACT I ON + Dll_ENDPOINT_EI 
CtlTransf erlnProgress = PROGRESS_IDLE; 
} 

else { 

D 1 1 CmdDa t aRe ad ( D 1 1_RE AD_LAS T_TRANS ACT I ON + Dll_ENDPOINT_EI 
WriteBuf f erToEndPoint () ; 

} 

} 

The If statements work down in order of priority. The highest priority interrupt is the 
USBJnit which re-initialises the USB function. The next highest priority is the defau 
and EP1 IN. This is where all the enumeration and control requests are sent. We br 
handle the EP0_OUT requests. 

When a request is made by the host and it wants to receive data, the PIC16F876 w 
byte packet. As the USbus is host controlled it cannot write the data when ever it de 
buffers the data and waits for an IN Token to be sent from the host. When the PDIU 
Token it generates an interrupt. This makes a good time to reload the next packet o 
by an additional function WriteBufferToEndpoint(); 

The section under CtlTransferlnProgress == PROGRESS ADDRESS handles the j 
address. We detail this later. 

if (Irq & Dll_INT_EPl_OUT) { 
printf ( "EPl_OUT\n\r" ) ; 

D 1 1 CmdDa t aRead ( D 1 1_READ_LAST_TRANS ACT ION + Dll_ENDPOINT_EPl_Ol 
bytes = DllReadEndpoint (Dll_ENDPOINT_EPl_OUT, Buffer); 
for (count = 0; count < bytes; count++) { 

circularbuf f er [inpointer++] = Buffer [count] ; 

if (inpointer >= MAX_BUFFER_SIZE) inpointer = 0; 

} 

loadf romcircularbuf f er ( ) ; //Kick Start 

} 

if (Irq & D11_INT_EP1_IN) { 
printf ("EPl_IN\n\r") ; 

D 1 1 CmdDa t aRe ad ( D 1 1_RE AD_L AS T_TRANS ACT I ON + D11_ENDP0INT_EP1_I> 
loadf romcircularbuf fer ( ) ; 

} 

EP1 OUT and EP1 IN are implemented to read and write bulk data to or from a circi 
the code to be used in conjunction with the BulkUSB example in the Windows DDK' 
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defined earlier in the code as being 80 bytes long taking up all of bankl of the PIC1 

if (Irq & Dll_INT_EP2_OUT) { 
printf ("EP2_OUT\n\r") ; 

D 1 lCmdDa t aRead ( D 1 1_READ_LAST_TRANS ACT ION + Dll_ENDPOINT_EP2_Ot 
Buffer [0] = 0x01; /* Stall Endpoint */ 

DllCmdDataWrite (Dll_SET_ENDPOINT_STATUS + Dll_ENDPOINT_EP2_OUT 

} 

if (Irq & D11_INT_EP2_IN) { 
printf ("EP2_IN\n\r") ; 

DllCmdDataRead (Dll_READ_LAST_TRANSACTION + Dll_ENDPOINT_EP2_If 
Buffer [0] = 0x01; /* Stall Endpoint */ 

DllCmdDataWrite (Dll_SET_ENDPOINT_STATUS + Dll_ENDPOINT_EP2_IN, 

} 

if (Irq & Dll_INT_EP3_OUT) { 
printf ( "EP3_OUT\n\r" ) ; 

DllCmdDataRead (Dll_READ_LAST_TRANSACTION + Dll_ENDPOINT_EP3_Ol 
Buffer [0] = 0x01; /* Stall Endpoint */ 

DllCmdDataWrite (Dll_SET_ENDPOINT_STATUS + D11_ENDP0INT_EP3_0U1 

} 

if (Irq & D11_INT_EP3_IN) { 
printf ("EP3_IN\n\r") ; 

DllCmdDataRead (Dll_READ_LAST_TRANSACTION + D11_ENDP0INT_EP3_I* 
Buffer [0] = 0x01; /* Stall Endpoint */ 

DllCmdDataWrite (Dll_SET_ENDPOINT_STATUS + D11_ENDP0INT_EP3_IN, 

} 

} 

Endpoints two and three are not used at the moment, so we stall them if any data is 
has a Set Endpoint Enable Command which can be used to enable or disable funct 
endpoints other than the default control pipe). We could use this command to diable 
were planning on not using these later. However at the moment this code provides ; 

void Process_EP0_OUT_Interrupt (void) 
{ 

unsigned long a; 
unsigned char Buffer [2] ; 
USB_SETUP_REQUEST SetupPacket; 

/* Check if packet received is Setup or Data - Also clears IRQ */ 
DllCmdDataRead (Dll_READ_LAST_TRANSACTION + Dll_ENDPOINT_EP0_OUT, &Set\. 

if (SetupPacket .bmRequestType & D 1 1_L AS T_TRAN_S ETUP ) { 

The first thing we must do is determine is the packet we have received on EP0 Out 
Packet. A Setup Packet contains a request such as Get Descriptor where as a data 
previous request. We are lucky that most requests do not send data packets from tl 
request that does is SET_DESCRIPTOR but is rarely implemented. 

/* This is a setup Packet - Read Packet */ 
DllReadEndpoint (Dll_ENDPOINT_EP0_OUT, &SetupPacket ) ; 

/* Acknowlegde Setup Packet to EP0_OUT & Clear Buffer*/ 
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DllCmdDataWrite (D11_ACK_SETUP, NULL, 0) ; 
DllCmdDataWrite (D11_CLEAR_BUFFER, NULL, 0); 

/* Acknowlegde Setup Packet to EP0_IN */ 
DllCmdDataWrite (Dll_ENDPOINT_EP0_IN, NULL, 0); 
DllCmdDataWrite (D11_ACK_SETUP, NULL, 0) ; 

/* Parse bmRequestType */ 

switch (SetupPacket .bmRequestType & 0x7F) { 

As we have seen in our description of Control Transfers , a setup packet cannot be I 
the PDIUSBD1 1 receives a Setup Packet it flushes the EPO IN buffer and disables 1 
Buffer commands. This ensures the setup packet is acknowledged by the microcon 
Acknowledge Setup command to both EPO IN and EPO OUT before a Validate or C 
effective. The recept of a setup packet will also un-stall a STALLed control endpoinl 

Once the packet has been read into memory and the setup packet acknowledged, v 
request starting with the request type. At the moment we are not interesting in the d 
bit. The three requests all devices must process is the Standard Device Request, S 
and Standard Endpoint Requests. We provide our functionality (Read Analog Inputs 
we add a case statement for Standard Vendor Requests. If your device supports a I 
you may also need to add cases for Class Device Request, Class Interface Reques 
Request. 

case STANDARD_DEVICE_REQUEST: 

printf ( "Standard Device Request "); 
switch (SetupPacket .bRequest) { 
case GET_STATUS : 

/* Get Status Request to Device should return */ 
/* Remote Wakeup and Self Powered Status */ 
Buffer [0] = 0x01; 
Buffer [1] = 0x00; 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, Buffer, 2 ) ; 
break; 

case CLEAR_FEATURE : 
case SET_FEATURE : 

/* We don't support DE VI CE_REMOTE_WAKEUP or TEST_N 

ErrorStallControlEndPoint () ; 

break; 

The Get Status request is used to report the status of the device in terms of if the d( 
and if it supports remote wakeup. In our device we report it as self powered and as 
wakeup. 

Of the Device Feature requests, this device doesn't support DEVICE_REMOTE_W/ 
and return a USB Request Error as a result. 

case SET_ADDRESS: 

printf ("Set Address\n\r " ) ; 

DeviceAddress = SetupPacket . wValue | 0x80; 
DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, NULL, 0) ; 
CtlTransf erlnProgress = PROGRESS_ADDRESS ; 
break; 
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The Set Address command is the only command that continues to be processed aft 
commands must finish processing before the status stage. The device address is re 
stored in a variable DeviceAddress. The OR'ing with 0x80 is specific to the PDIUSB 
bit indicating if the device is enabled or not. A zero length packet is returned as stat 
command is complete. However the host must send an IN Token, retrieve the zero 
ACK before we can change the address. Otherwise the device may never see the II 
default address. 

The completion of the status stage is signalled by an interrupt on EPO IN. In order tc 
address response and a normal EPOJN interrupt we set a variable, CtlTransferlnPr 
PROGRESS_ADDRESS. In the EPO IN handler a check is made of CtlTransferlnPr 
PROGRESS_ADDRESS then the Set Address Enable command is issued to the PI 
CtlTransferlnProgress is set to PROGRESSJDLE. The host gives 2ms for the devii 
before the next command is sent. 

case GET_DESCRIPTOR : 

GetDescriptor (&SetupPacket) ; 
break; 

case GET_CONFIGURATION : 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, &DeviceConf i 
break ; 

case SET_CONFIGURATION: 

printf ("Set Conf iguration\n\r " ) ; 
DeviceConf igured = SetupPacket . wValue & OxFF; 
DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, NULL, 0); 
if (DeviceConf igured) { 
RB3 = 0; 

printf ("\n\r *** Device Configured *** \n\r"); 

} 

else { 

RB3 = 1; /* Device Not Configured */ 

printf ("\n\r ** Device Not Configured *** \n\i 

} 

break; 

//case SET_DESCRIPTOR: 
default : 

/* Unsupported - Request Error - Stall */ 

ErrorStallControlEndPoint () ; 

break; 

} 

break; 

The Get Configuration and Set Configuration is used to "enable" the USB device all 
on endpoints other than endpoint zero. Set Configuration should be issued with wV< 
bConfigurationValue of the configuration you want to enable. In our case we only h£ 
configuration 1 . A zero configuration value means the device is not configured while 
value indicates the device is configured. The code does not fully type check the con 
copies it into a local storage variable, DeviceConf igured. If the value in wValue doe; 
bConfigurationValue of a Configuration, it should return with a USB Request Error. 

case STAND ARD_INTERFACE_REQUEST : 
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printf ( "Standard Interface Request\n\r " ) ; 
switch (SetupPacket .bRequest) { 

case GET_STATUS : 

/* Get Status Request to Interface should return * 
/* Zero, Zero (Reserved for future use) */ 
Buffer [0] = 0x00; 
Buffer [1] = 0x00; 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, Buffer, 2); 
break; 

case SET_INTERFACE : 

/* Device Only supports default setting, Stall ma> 
/* returned in the status stage of the request */ 
if (SetupPacket .wlndex == && SetupPacket . wValue 
/* Interface Zero, Alternative Setting = */ 
DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, NULL, 0) 
else ErrorStallControlEndPoint ( ) ; 
break; 

case GET_INTERFACE : 

if (SetupPacket .wlndex == 0) { /* Interface Zero * 
Buffer [0] =0; /* Alternative Setting */ 
DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, Buffer, 
break; 

} /* else fall through as RequestError */ 

//case CLEAR_FEATURE : 
//case SET_FEATURE: 

/* Interface has no defined features. Return Reque 
default : 

ErrorStallControlEndPoint () ; 

break; 

} 

break; 

Of the Standard Interface Requests, none perform any real function. The Get Statu; 
of zero and is reserved for future use. The Set Interface and Get Interface requests 
Interface Descriptors. We have not defined any alternative Interface Descriptors so 
and any request to Set an interface other than to set interface zero with an alternatr 
processed with a Request Error. 

case STAND ARD_ENDPOINT_REQUEST : 

printf ( "Standard Endpoint Request\n\r " ) ; 
switch (SetupPacket .bRequest) { 

case CLEAR_FEATURE : 

case SET_ FEATURE : 

/* Halt (Stall) feature required to be implemented 
/* Bulk Endpoints. It is not required nor recommer 

if (SetupPacket .wValue == ENDPOINT HALT) 
{ 

if (SetupPacket .bRequest == CLEAR_FEATURE ) Buf 
else Bui 
switch (SetupPacket .wlndex & OxFF) { 

case 0x01 : DllCmdDataWrite (Dll SET ENDPO] 
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D11_ENDP0INT_EP1_0UT, Buffei 
break; 

case 0x81 : DllCmdDataWrite (Dll_SET_ENDPO: 
D11_ENDP0INT_EP1_IN, Buffer, 
break; 

case 0x02 : DllCmdDataWrite (D11_SET_ENDP0] 
Dll_ENDPOINT_EP2_OUT, Buffei 
break; 

case 0x82 : DllCmdDataWrite (D11_SET_ENDP0] 
Dll_ENDPOINT_EP2_IN, Buffer, 
break; 

case 0x03 : DllCmdDataWrite (Dll_SET_ENDPO] 
Dll_ENDPOINT_EP3_OUT, Buffei 
break; 

case 0x83 : DllCmdDataWrite (D11_SET_ENDP03 
D11_ENDP0INT_EP3_IN, Buffer, 
break; 

default : /* Invalid Endpoint - Request! 

ErrorStallControlEndPoint ( ) ; 
break; 

} 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, NULL, 0) 
} else { 

/* No other Features for Endpoint - Request Ei 
ErrorStallControlEndPoint () ; 

} 

break; 



The Set Feature and Clear Feature requests are used to set endpoint specific featu 
one endpoint feature selector, ENDPOINTHALT. We check what endpoint the reqi 
set/clear the STALL bit accordingly. This HALT feature is not required on the defaul 

case GET_STATUS : 

/* Get Status Request to Endpoint should return */ 
/* Halt Status in DO for Interrupt and Bulk */ 
switch (SetupPacket . wlndex & OxFF) { 

case 0x01 : DllCmdDataRead (Dl l_READ_ENDPOINT_£ 
Dll_ENDPOINT_EPl_OUT, Buffer, 1) 
break; 

case 0x81 : DllCmdDataRead (Dll_READ_ENDPOINT_£ 
D11_ENDP0INT_EP1_IN, Buffer, 1) ; 
break; 

case 0x02 : DllCmdDataRead (Dll_READ_ENDPOINT_£ 
Dll_ENDPOINT_EP2_OUT, Buffer, 1) 
break; 

case 0x82 : DllCmdDataRead (Dll_READ_ENDPOINT_£ 
Dll_ENDPOINT_EP2_IN, Buffer, 1) ; 
break; 

case 0x03 : DllCmdDataRead (Dll_READ_ENDPOINT_£ 
Dll_ENDPOINT_EP3_OUT, Buffer, 1) 
break; 

case 0x83 : DllCmdDataRead (Dll_READ_ENDPOINT_£ 
Dll_ENDPOINT_EP3_IN, Buffer, 1) ; 
break; 

default : /* Invalid Endpoint - RequestErroi 
ErrorStallControlEndPoint () ; 
break; 

} 
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if (Buffer [0] & 0x08) Buffer [0] = 0x01; 
else Buffer [0] = 0x00; 

Buffer [1] = 0x00; 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, Buffer, 2); 
break; 

default : 

/* Unsupported - Request Error - Stall */ 

ErrorStallControlEndPoint ( ) ; 

break; 

} 

break; 

The Get Status request when directed to the endpoint returns the status of the endp 
Like the Set/Clear feature request ENDPOINT HALT, we only need to report the st« 

Any undefined Standard Endpoint Requests are handled by USB Request Error. 

case VENDOR_DEVICE_REQUEST : 
case VENDOR_ENDPOINT_REQUEST: 

printf ( "Vendor Device bRequest = 0x%X, wValue = 0x%X, wine 
SetupPacket .bRequest , SetupPacket . wValue , SetupPacket . 

switch (SetupPacket .bRequest) { 

case VENDOR_GET_ANALOG_VALUE : 

printf ("Get Analog Value, Channel %x : " , SetupPacke 

ADCON0 = OxCl | (SetupPacket .wlndex & 0x07) << 3; 

/* Wait Acquistion time of Sample and Hold */ 

for (a = 0; a <= 255; a++) ; 

ADGO = 1; 

while (ADGO) ; 

Buffer [0] = ADRESL; 

Buffer [1] = ADRESH; 

a = (Buffer [1] << 8) + Buffer[0]; 

a = (a * 500) / 1024; 

printf (" Value = %d . %02d\n\r" , (unsigned int)a/100, 
DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, Buffer, 2 ) ; 
break; 

Now comes the functional parts of the USB device. The Vendor Requests can be di 
We have dreamed up two requests, VENDOR_GET_ANALOG_VALUE and VEND( 
VENDOR_GET_ANALOG_VALUE reads the 10-bit Analog Value on Channel x did 
ANDed with 0x07 to allow 8 possible channels, supporting the larger PIC16F877 if r 
returned in a two byte data packet. 

case VENDOR_SET_RB_HIGH_NIBBLE : 

printf ("Write High Nibble of PORTB\n\r " ) ; 

PORTB = (PORTB & OxOF) | (SetupPacket . wlndex & OxI 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, NULL, 0); 

break; 

default : 

ErrorStallControlEndPoint () ; 
break; 

} 

break; 
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The VENDOR_SET_RB_HIGH_NIBBI_E can be used to set the high nibble bits of F 

default : 

printf ("Unsupported Request Type Ox%X\n\r" , SetupPacket .bmf 

ErrorStallControlEndPoint () ; 

break; 

} 

} else { 

printf ("Data Packet?\n\r " ) ; 
/* This is a Data Packet */ 

} 

} 



Any unsupported request types such as class device request, class interface requei 
Request Error. 

void GetDescriptor (PUSB_SETUP_REQUEST SetupPacket) 
{ 

switch ( (SetupPacket- >wValue & OxFFOO) >> 8) { 

case TYPE_DEVICE_DESCRIPTOR: 

printf ( "\n\rDevice Descriptor: Bytes Asked For %d, Size of Des 

SetupPacket - >wLength, DeviceDescriptor . bLength) ; 
pSendBuffer = (const unsigned char * ) &DeviceDescriptor ; 
BytesToSend = DeviceDescriptor . bLength; 
if (BytesToSend > SetupPacket - >wLength) 
BytesToSend = SetupPacket - >wLength; 
WriteBuf f erToEndPoint () ; 
break; 

case TYPE_CONF IGURAT I ON_DE S CR I PTOR : 

printf ( "\n\rConf iguration Descriptor: Bytes Asked For %d, Size 
SetupPacket- >wLength, sizeof (Conf igurationDescriptor) ) 
pSendBuffer = (const unsigned char *) &Conf igurationDescriptor ; 
BytesToSend = sizeof (Conf igurationDescriptor) ; 
if (BytesToSend > SetupPacket ->wLength) 
BytesToSend = SetupPacket ->wLength; 
WriteBuf f erToEndPoint () ; 
break; 



The Get Descriptor requests involve responses greater than the 8 byte maximum p; 
endpoint. Therefore they must be broken up into 8 byte chunks. Both the Device an 
the address of the relevant descriptors into pSendBuffer and sets the BytesToSend 
descriptor. The request will also specify a descriptor length in wLength specifying th 
each case we check the actual length against that of what the host has asked for ar 
Then we call WriteBuffertoEndpoint which loads the first 8 bytes into the endpoint b 
pointer ready for the next 8 byte packet. 

case TYPE_STRING_DESCRIPTOR: 

printf ( "\n\rString Descriptor: LANGID = 0x%04x, Index %d\n\r", 

SetupPacket->wlndex, SetupPacket - >wValue & OxFF) ; 
switch ( SetupPacket ->wValue & OxFF) { 

case : pSendBuffer = (const unsigned char * ) &LAMGID_Des 
BytesToSend = sizeof (LANGID_Descriptor ) ; 
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break; 

case 1 : pSendBuffer = (const unsigned char * ) &Manuf actui 
BytesToSend = sizeof (Manuf acturer_Descriptor) ; 
break; 

default : pSendBuffer = NULL; 

BytesToSend = 0; 

} 

if (BytesToSend > SetupPacket - >wLength) 
BytesToSend = SetupPacket->wLength; 
WriteBuf ferToEndPoint () ; 
break; 

If any string descriptors are included, there must be a string descriptor zero present 
languages are supported by the device. Any non zero string requests have a Langu 
telling what language to support. In our case we cheat somewhat and ignore the va 
returning the string, no matter what language is asked for. 

default : 

ErrorStallControlEndPoint () ; 
break; 

} 

} 

void ErrorStallControlEndPoint (void) 
{ 

unsigned char Buffer [] = { 0x01 }; 

/* 9.2.7 RequestError - return STALL PID in response to next DATA Stac 
DllCmdDataWrite (Dll_SET_ENDPOINT_STATUS + Dll_ENDPOINT_EP0_IN, Buffer, 
/* or in the status stage of the message. */ 

DllCmdDataWrite (Dll_SET_ENDPOINT_STATUS + Dll_ENDPOINT_EP0_OUT, Buffei 

} 

When we are faced with an invalid request, invalid parameter or a request the devic 
report a request error. This is defined in 9.2.7 of the specification. A request error w 
response to the next data stage transaction or in the status stage of the message. r 
prevent unnecessary bus traffic the error should be reported at the next data stage 
status stage. 

unsigned char DllReadEndpoint (unsigned char Endpoint, unsigned char *Buffe 
{ 

unsigned char DllHeader [2 ] ; 
unsigned char BufferStatus = 0; 

/* Select Endpoint */ 

DllCmdDataRead (Endpoint, &Buf f erStatus , 1) ; 

/* Check if Buffer is Full */ 

if (BufferStatus & 0x01) 

{ 

/* Read dummy header - Dll buffer pointer is incremented on each i 
/* and is only reset by a Select Endpoint Command */ 
DllCmdDataRead (D11_READ_BUFFER, DllHeader, 2); 

if (DllHeader [1] ) DllCmdDataRead (D11_READ_BUFFER, Buffer, DllHeadei 
/* Allow new packets to be accepted */ 
DllCmdDataWrite (D11_CLEAR_BUFFER, NULL, 0); 
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} 

return DllHeader [1] ; 

1 

void DllWriteEndpoint (unsigned char Endpoint, const unsigned char *Buffer, 

{ 

unsigned char DllHeader [2 ] ; 
unsigned char BufferStatus = 0; 
DllHeader [0] = 0x00; 
DllHeader [1] = Bytes; 

/* Select Endpoint */ 

DllCmdDataRead (Endpoint, &Buf f erStatus , 1) ; 
/* Write Header */ 

D 1 1 CmdDa t aWr i t e ( D 1 1_WR I TE_BUF FER , DllHeader, 2 ) ; 
/* Write Packet */ 

if (Bytes) D 1 1 CmdDa t aWr i t e ( D 1 1_WR I TE_BUF FER , Buffer, Bytes); 
/* Validate Buffer */ 

DllCmdDataWrite (D11_VALIDATE_BUFFER, NULL, 0); 

} 

D1 1 ReadEndpoint and D1 1 WriteEndpoint are PDIUSBD1 1 specific functions. The F 
bytes prefixing any data read or write operation. The first byte is reserved, while the 
number of bytes received or to be transmitted. These two functions take care of this 

void WriteBuf f erToEndPoint (void) 
{ 

if (BytesToSend == 0) { 

/* If BytesToSend is Zero and we get called again, assume buffer i 

/* than Setup Request Size and indicate end by sending Zero Lenght 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, NULL, 0); 
} else if (BytesToSend >= 8) { 

/* Write another 8 Bytes to buffer and send */ 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, pSendBuffer, 8); 

pSendBuffer += 8 ; 

BytesToSend -= 8 ; 
} else { 

/* Buffer must have less than 8 bytes left */ 

DllWriteEndpoint (Dll_ENDPOINT_EP0_IN, pSendBuffer, BytesToSend) ; 
BytesToSend = ; 

} 

} 

As we have mentioned previously, WriteBufferToEndPoint is responsible for loadinc 
8 byte chunks and adjusting the pointers ready for the next packet. It is called once 
load the first 8 bytes into the endpoint buffer. The host will then send an IN token, re 
PDIUSBD1 1 will generate an interrupt. The EP0 IN handler will then call WriteBuffe 
next packet in readiness for the next IN token from the host. 

A transfer is considered complete if all requested bytes have been read, if a packet 
less than bMaxPacketSize or if a zero length packet is returned. Therefore if the By 
we assume the data to be sent was a multiple of 8 bytes and we send a zero length 
last of the data. However if we have less than 8 bytes left to send, we send only the 
need to pad the data with zeros. 

void loadf romcircularbuf f er (void) 
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{ 

unsigned char Buffer [10]; 
unsigned char count; 

// Read Buffer Full Status 

D 1 1 CmdDa t aRead ( D 1 l_ENDPO INT_EP 1_IN , Buffer, 1) ; 

if (Buffer [0] == 0) { 
// Buffer Empty 
if (inpointer != outpointer) { 

//We have bytes to send 

count = ,- 

do { 

Buf f er [count++] = circularbuf f er [outpointer++] ; 
if (outpointer >= MAX_BUFFER_SIZE) outpointer = 0; 
if (outpointer == inpointer) break; //No more data 
} while (count < 8); // Maximum Buffer Size 
// Now load it into EPl_In 

DllWriteEndpoint (D11_ENDP0INT_EP1_IN, Buffer, count); 
} 

} 

} 

The loadfromcircularbufferO routine handles the loading of data into the EP1 IN end 
called after an EP1 IN interrupt to reload the buffer ready for the next IN token on E 
out first packet, we need to load the data prior to receiving the EP1 IN interrupt. The 
called after data is received on EP1 OUT. 

By also calling the routine from the handler for EP1 OUT, we are likely to overwrite » 
regardless of whether it has been sent or not. To prevent this, we determine if the E 
we attempt to reload it with new data. 

void DllCmdDataWrite (unsigned char Command, const unsigned char *Buffer, u 
{ 

I2C_Write (D11_CMD_ADDR, &Command, 1) ; 

if (Count) I2C_Write (D11_DATA_ADDR_WRITE , Buffer, Count); 

} 

void DllCmdDataRead (unsigned char Command, unsigned char Buffer [], unsigne 
{ 

I2C_Write (D11_CMD_ADDR, &Command, 1) ; 

if (Count) I2C_Read(Dll_DATA_ADDR_READ, Buffer, Count); 

} 

D1 ICmdDataWrite and D1 ICmdDataRead are two PDIUSBD1 1 specific functions \ 
sending the I2C Address/Command first and then send or received data on the I2C 
functions are included in the source code but have not been reproduced here as it b 
USB specific details. 

This example can be used with the bulkUSB.sys example as part of the Windows D 
bulkUSB.sys driver either change the code to identify itself with a VI D of 0x045E an 
the bulkUSB.inf file accompanying bulkUSB.sys to match the VID/PID combination 

It is then possible to use the user mode console program, rwbulk.exe to send and n 
circular buffer. Use 
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based upon code written by Michael and been eftortlessfy developed on the US BLPT-PD 
development board before being ported to the PIC. 

Downloading the Source Code 

o Versi on 1 . 2. 14k bytes 

Revision History 

■ 6th April 2002 - Version 1 .2 - Increased I2C speed to match that of comr 
IRQ Handling 

> 7th January 2002 - Version 1.1- Added EP1 IN and EP1 OUT Bulk hanc 
descriptors load from FLASH 

■ 31st December 2001 - Version 1.0. 
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